Object oriented programming is well known and very well established. Examples of object oriented programming languages include C++ and Smalltalk. Object oriented programming may be viewed as including polymorphism and inheritance, along with some encapsulation and some late binding. Object oriented programming initially was expected to allow for a great deal of object re-use, where objects are created once, and shared or sold for less than the cost and uncertainty of developing the same or similar objects from scratch for different projects and within different organization. The promise of object re-use was not immediately realized. What little re-use was provided was often in the form of class source code in one language that would hopefully compile across multiple platforms.
Languages like C++ offer encapsulation, meaning the encapsulation of data, by separating the data from the access to that data. Encapsulation may be viewed as separating what an object looks like, e.g., the object interface, from how it actually works, e.g., the object implementation. C++ provides encapsulation, but in effect provides both interface and implementation simultaneously. Attempts have been made to separate the implementation from the interface, with varying degrees of success.
Object oriented programming provided more reusability with the advent of object-oriented programming that was more component oriented. Such component oriented programming may be viewed as including polymorphism, interface inheritance, very late binding, enforced encapsulation, and binary reuse. One commercial embodiment of component-oriented programming was Object Linking and Embedding (OLE), from Microsoft®. A later commercial embodiment of component oriented programming, derived from OLE, included Component Object Model (COM) objects, also provided by Microsoft®.
COM objects provided interfaces separate from implementation, and allowed for multiple interfaces to each object. COM objects support the IUnknown interface, among others. COM further supports the inheritance of interfaces. Interfaces can be added or extended by users, enhancing the reusability. Components created that derive from IUnknown must support the IUnknown interface, and can support other interfaces, which are defined in an Interface Definition Language (IDL). A developer can use a system such as COM to create objects which, when compliant with COM, can be created as binary objects, used, and extended by a purchaser or user on remote computers.
Binary objects having agreed upon and/or published interfaces can be created, used, and destroyed using these interfaces. Making the objects persistable is also desirable. Interfaces have been defined to make objects, for example, COM objects, to be persistently stored and restored from persistent storage. Due to the extensibility of the objects, while the interfaces are defined, the implementation is left to the developer of the COM compliant object. Storing and restoring objects can be less than straightforward as the objects often have points referencing other objects, which will be in different locations when restored, and may not be in existence at the point in time when the pointer value is to be restored.
What would be desirable, therefore, are methods and systems for providing persistent storage and retrieval for objects having pointers, and in particular, methods and systems for storing and restoring objects derived from component objects having defined interfaces.